According to conventional software development techniques, an automated code counting tool is triggered when integrating code into official library to determine the number of lines present. Comparison with a previous version of the file is computed while the code checking in, allowing the developer to evaluate the impact of the change in terms of lines of code added.
This information is collected for each production build to build up a curve as shown in FIG. 1. FIG. 1 shows a curve 101 of expected values, and curve 102 representing actual count values as determined by the code counting tool for a product release starting from an existing code base on top of which the new one is to be developed. The predicted curve is prepared starting from the design of the new product and prototypes of its various components. With these two elements, development teams typically calculate the expected amount of code that will be produced. As can be seen in this example, the values from the start of the project until 23rd March substantially fit the projected curve. The count for the 4th April however shows a substantial deviation from the expected count value. In such a case where the curve is not as expected, typically the quantity of integrated code is higher than planned, a backward analysis is conducted to understand which are the tracks that are responsible for the measured deviation. Such deviations originate either from an erroneous assumption, which means that the design or prototype were insufficient, or code has been added for functionalities that were not planned at the beginning, or in a worst case unnecessary code has been written
FIG. 2 shows a method of software development according to the prior art approach described with respect to FIG. 1. The method starts at step 201, and proceeds at step 203 to add code to the project. This will generally be in the context of a particular module or other functional subdivision of the program, which is intended to perform a particular task. Once the programmer or development team completes the module, as determined at step 205, the project as a whole is compiled or “built” at step 207, incorporating the new module. The quantity of code constituting the complete project is next measured or counted. In some cases as described above, the code added at step 203 may be anomalous, for example in that it contains more or less code than would normally be expected for code implementing the functions of such a module. Such an anomaly will therefore be apparent in the code count value determined at step 209. At step 211 it is accordingly determined whether the project contains an anomalous quantity of code. In a case where the project is found to contain an anomalous quantity of code, the method proceeds to step 213, at which the project as a whole is analysed, to identify the anomaly. Once the anomaly is identified, the code can be repaired at step 215 before considering at step 217 whether the project is now complete. In a case where the project is found at step 211 to have the expected quantity of code, it is then considered at step 217 whether the project is now complete. If the project is complete, the method ends at step 219. Otherwise, the method returns to step 203 to begin work on the next section of the project.